Subject: Week 4 status: Connect/Disconnect working group.

From: alan bartky <[email-masked]>
Date: Mon, 26 Jul 93 11:51:07 PDT

Fellow Connect/Disconnectors:

We are now on our fourth week.  It is my opinion that we did not meet
last weeks objective and contributions were fairly light.  If we are
going to improve RFC1434 in order to more fully support SNA/SDLC, LAN and 
NETBIOS (as per our goal), we will have to "roll up our sleeves" and get
to work!

Here is the agenda as it currently stands:

Last Week:

7/19-23 Email Discussions of Formal Proposals.  Goal to reach
        consensus on basic technical methods proposed and start of 
        detailed work on working group document for connect/disconnect
        sequences.  Edited Formal Submissions (based on comments) to be
        submitted.

Remaining work:

7/26-30 Final discussions on proposals.  Goal to have first draft document
        by Friday.

8/2-6   Discussion/ Comments on first draft of Connect/Disconnect document.
        Technical, Editorial, Content.  New submissions to be additions
        changes to the document.  Goal to have second draft document
        by Friday.

8/9-13  Discussions/Comments on Second Draft Documents.  New submissions 
        at this point should be only to aid in completion or clarification
        of the work in progress.  Goal to have review copy of final Draft 
        by Friday.

8/16-20 Discussions on Final Draft.  Changes to the document should
        be editorial in nature.  Edited final draft ready to go by Friday.

8/23-27 Final Discussions, Document submitted to the AIW.  (Note: This
        is also the week of fall Interop).

8/30-9/3 Initial feedback from the AIW (non connect/disconnect members)
        Answers from Group members to the AIW.  Any discussion within
        working group as needed.  Blatant errors (editing or technical)
        to be corrected by group consensus.  Any final changes to be
        resubmitted to AIW by Friday.  (NOTE:  THIS IS THE TWO WEEK
        FINAL DEADLINE PRIOR TO THE NEXT AIW).

9/6-17  (Two weeks)  Open discussion period, Questions/Answers to rest of
        AIW.  Any proposed changes to the document will be logged and 
        presented in open forum at the AIW.

9/21-23 AIW Meeting, Raleigh NC.

As you can see, we did not meet last week's goal.  We need to get some
proposals, otherwise DLSw connect/disconnect sequences will not get improved
to allow other options (e.g. SDLC to SDLC).  I don't think that is the desire
of the group.  I will create a revised agenda, based on how much input we get
in the next couple of days.  I certainly don't think we'll be ready
for a draft document this week.

One thing that might make our job easier is to use the ASCII text
version of RFC1434 to do our editing and to use as a base for submitting
proposals.  Below is a sample flow diagram from the ASCII text version of
RFC1434:

###################
begin included text
###################

RFC 1434             DLS: Switch-to-Switch Protocol           March 1993

   Data Link  Data Link                         Data Link  Data Link
    Control    Switch                            Switch     Control
   --------------------                         --------------------
      +------------+                                 +------------+
      |Disconnected|                                 |Disconnected|
      +------------+                                 +------------+
Test Command                  CANUREACH                     Test Comd.
  ---------->    --------------------------------------->     ------->
 (DSAP=Null)                 (DSAP=SSAP)
                                                         Test Response
                              ICANREACH                     <---------
Test Response    <---------------------------------------
  <----------                 REACH ACK
                 --------------------------------------->
      +------------+                                 +------------+
      |Circuit Est.|                                 |Circuit Est.|
      +------------+                                 +------------+
    SABME                      CONTACT
  ---------->    --------------------------------------->     SABME
      UA                                                      ------->
  <----------
     RNR                                                        UA
  <----------                 CONTACTED                      <-------
                 <---------------------------------------
      +------------+                                 +------------+
      | Connected  |                                 | Connected  |
      +------------+                                 +------------+
      RR
   <---------

               Figure 4.  DLS Connect  Message Protocols

   Upon receipt of a Test command from the origin station, the origin
   DLS will send a CANUREACH (i.e., can you reach) message to the target
   DLS.  If the target DLS is not known to the origin DLS, the CANUREACH
   message is sent to all remote Data Link Switches defined to the
   origin DLS.  The receipt of the CANUREACH message causes the target
   DLS to send a Test command searching for the target station.  The
   target station will return a Test response, causing the target DLS to
   return an ICANREACH (i.e., I can reach) message to the origin DLS.
   If multiple Data Link Switches can reach the target station, the
   origin DLS will receive multiple ICANREACH messages.  The origin DLS
   will select the first message and send a REACH_ACK (i.e., reach
   acknowledgment) message to the selected Data Link Switch.  During
   this exchange of messages, both Data Link Switches change states from
   the Disconected state to the Circuit Established state.  Once the
   circuit is established, Type-1 frames, such as XID, may be exchanged
   between the origin and target stations.

   To establish a connection, the origin station sends a SABME command.
   Upon receipt of this command, the origin DLS will send a CONTACT
   message to the target DLS and return a UA response to the origin
   station.  To inhibit traffic flow until the connection is established
   to the remote station, a RNR supervisory frame is sent to the origin
   station.  The CONTACT message will cause the target DLS to send a
   SABME command to the target station, which in return will reply with
   a UA response.  Upon receipt of the UA response, the target DLS will
   send a CONTACTED message to the origin DLS.  The origin DLS will now
   send an RR supervisory frame to the origin station.  During this
   exchange of messages, both Data Link Switches change states from the
   Circuit Established state to the Connected state.

   For NetBIOS end systems, the protocol flows are similar but employ
   different frames and SSP messages.  Instead of using a Test command
   frame to initiate the circuit, a NetBIOS system will use a Name Query
   frame.  Receipt of a Name Query frame will cause the Data Link Switch
   to issue a NETBIOS_NQ message instead of the CANUREACH message.  In a
   like fashion, the Test response is replaced with a Name Recognized
   frame and the ICANREACH message is replaced with a NETBIOS_NR
   message.  As with the SNA protocol flows, the receipt of a NETBIOS_NR
   message causes the origin Data Link Switch to respond with a
   REACH_ACK message.

#################
end included text
#################

Hopefully using these diagrams we can do some cut and paste in proposing
any small changes to the protocol to accomplish our goals.  If nothing else
this group should do is to better describe the protocol specifics (e.g. 
How Source Routing works, Virtual Ring numbering, etc.).

If proposals for major change are to be made, either let's see them, or at
least I need people that are interested in a major change to identify
themselves and commit to work.  (e.g. Changing the circuit establishment 
at SABME rather than TEST frame, ala Cisco's STUN approach).

Also if IBM has any changes that they have made to the ASCII version
of RFC1434, they should publish it to the group.  We should have the 
latest copy to work on.

If SSP is to work as a protocol that is accepted by SNA Network Managers,
then it must work between various Vendor's equipment and provide them
the connectivity that they need.

Here are my goals from last week, just to remind everybody that we have
a large amount of work to do:

As far as our mainline problem of solving connect and disconnect sequences,
we need to get going on getting some real proposals going on how
to make this protocol work.  Here's what I propose to use for discussing
different methods (challenge for the week):

Come up with a proposal that will handle the following flows, provide
detail for the middle that will work under the various cases:

SNA/SDLC <----> Network <-> SNA/SDLC
SNA/SDLC <----> Network <-> SNA/LLC
SNA/LLC <-----> Network <-> SNA/SDLC
SNA/LLC <-----> Network <-> SNA/LLC
NETBIOS <-----> Network <-> NETBIOS

For SNA both PU 2.0 and PU2.1 cases will be worked on (any opinions on
supporting other PU types?)

As the line from the fairy tale goes: "And who will help me bake the
bread".

We need participants, not just readers.  Lets get going!

Regards,
Alan

---

From: "Jim (J.) Cobban" <[email-masked]>
Date: Tue, 3 Aug 1993 14:57:00 +0000

In message "Week 4 status: Connect/Disconnect working group.", 

>at SABME rather than TEST frame, ala Cisco's STUN approach).
Given that:

There are many implementations of LLC2 which perform a single TEST exchange
with a NULL DSAP to determine the source route to a particular remote MAC
address, and then establish multiple LLC2 connections using SABME and a
combination of SSAP, DSAPs which may have little relationship to the SSAP
used in the TEST.

And, there are many applications, other than SNA and NetBIOS which support
source routing, and which must be carried in parallel through a bridge which
also supports DLS for SNA and NetBIOS.

I cannot understand why carriage of source-route explorer frames, whether
TESTs, Name Querys or whatever, should be a particular responsibility of
DLS.  DLS is made significantly more complicated by the requirement to
carry source route explorer frames for which there are other mechanisms.
There is obvious benefit to LLC2 to DLS and SDLC to DLS conversion for:

  - reduction of supervisory frame traffic
  - elimination of unnecessary retransmissions of I frames
  - elimination of spurious connection failures through long time-outs
  - traffic reduction through elimination of MAC headers

among other benefits.  However it is not obvious how a data-link switch can
improve the handling of frames outside of NRM/ABM such as the numerous UI
frames used in NetBIOS.  Interworking between serial links and LAN
implementations is not something which can be generalized, since each
protocol stack (SNA, IP, etc.) has defined its own mechanisms for carrying
traffic over different media.  For example it would be pointless to take an
IP frame off a token-ring LAN and place it on a serial link as the UI
frame which it appears to be.

It therefore appears to me that DLS had been made more complex than it needs
to be to solve the real problems associated with carrying the LLC2 traffic
characteristic of SNA and NetBIOS.  This complexity appears to have been
introduced in order to permit evolution to a hypothetical more general
data link switch, when such evolution appears unlikely, and would provide
little real benefit.

I would therefore suggest that the scope of the end-to-end protocol should be
limited to carriage of LLC2/SDLC traffic.  All frames which are not part of
the ABM/NRM aspect of this traffic should be carried as normal bridged
traffic over IP.  SABME (or SNRM[E] translated to SABME) should be the
command which initiates the logical connection.

---

From: [email-masked]
Date: Wed, 04 Aug 93 00:07:58 PDT

>also supports DLS for SNA and NetBIOS.

[email-masked] comments:
    True.  I would imagine most of the vendors in this working group also
    are either already supporting or interested in supporting Novell source
    routing.

>command which initiates the logical connection.

[email-masked] comments:
    I think this proposal has a lot of merit for a couple of reasons:
	(1) There has been some discussion in the Capabilities SIGlet
	    about a Directory Service/Name Service.  If the source
	    station knows the destination DLSw IP address a priori, then
	    the CANUREACH/ICANREACH is unnecessary anyway.  The mode
	    setting command should initiate the logical connection (like
	    Jim's proposal).
	(2) Since the capabilities exchange is supposed to happen prior
	    to any connection dialogue, the capabilities could identify
	    any of the following:
	    (a) CANUREACH/ICANREACH required ... 6611 default mode
	    (b) CANUREACH/ICANREACH optional ... a priori knowledge of
		path to destination
	    (c) bridge the discovery protocol over IP (Jim's proposal).

    Comments?

Wayne